Part 51: Assignment #24: Traffic Signal
Traffic Signal
I knew Mr. Haotian wouldn't be able to stay away. We put serious work into our designs here.
Let's see what he has for us this time.
This would be a really, REALLY simple job if the 'emergency vehicles' clause wasn't in there. You just set up a single MC that looped endlessly.
Heck, it would still be a simple job if the cycle restarted where it left off after the emergency vehicle was gone - you could save the state of the cycle in a MC and have it run only when 'emergency' was inactive.
With the 'restart cycle' provision, though, I don't know if it's possible (though fitting it in a single MC6000 would be really nice). I'll make a stab at it and see how far I get - trying to work on the problem should give me an impression of how complex it is.
[ ~ ]
Iiiiit's pretty complex, actually. I have to keep track of what phase I'm in, AND time how much is left in each phase. (And whether the emergency signal is on, of course.)
My solution is to split the job into two MCs. The MC on the left is the main one - it uses its acc to keep track of the state of the lights. The light state goes from 1, to 10, to 100, then back to 1 - stopping at 0 if the emergency signal is lit. (When this number is passed to the output expander, it toggles the lights in 0-1-2 order. This is why the wiring is so wonky by the outputs - to have expander output 0 connect to light 0, expander output 1 connect to light 1, and so on.)
Each time unit (assuming the emergency signal isn't on), the left (main) MC sends a 'count' signal ( 0 ) to the MC on the right. The MC on the right's job is just to keep track of timing. The right (timer) MC keeps track of the time left in the current phase in its acc, and time it receives a 'count' signal, it subtracts one from that. It returns the amount of time left to the main MC.
The main MC does nothing if the amount of time left in the phase is greater than 0. If it's 0, though, it shifts phases - it moves the light state along the 1-10-100 path, then sends that value to the output expander (changing the lights) AND to the timer MC. This acts as a 'new phase' signal.
When the MC on the right gets a 'new phase' signal ( > 0 ), it checks which phase is being asked for, then moves that number into its acc, to wait until the main MC calls for it. This cycle repeats endlessly, unless the emergency input turns on.
If the emergency input turns on, the main MC turns off the lights and sends a 'reset' ( -1 ) signal to the timer MC. This makes the timer MC to set its acc to 0*— nothing else. The reason this works is that, when the emergency input goes off, the main MC asks how much time is left in the phase. It's told 'none', so it starts the next phase - which, thanks to a special-case condition in the phase-change code, is always the first phase again. As expected.
*Technically it sets it to 1, but that's because the sub at the end of the timer MC sets it to 0 before that MC waits for new input.
The finished product is ¥11, and 755 power on average. I think there's room for improvement, though - the code just... feels clunky. I'll play around with it and see what comes up.
[ ~ ~ ]
It turns out that you can get better results by refactoring the code! This version is ¥9, and uses 418 power per run on average.
The upper (timer) MC still checks how much time is left, and it still relies on the other MC to tell what phase is up next. The difference is that while (in the previous design) the main MC always queried the timer, every time unit, now the timer MC is the main MC! It only signals the small MC if all lights need to be turned off (0) or cycled to the next phase (1).
The small MC keeps track of what phase we're in, but only acts when signaled - which is all it really needs to do, so it's more efficient all around.
This is about as far as I was able to take it. I tried to make it work with one MC6000, but I kept ending up with exactly 15 lines of code (one over) and eventually gave up**. But this feels like a pretty clean solution.
**I'm not posting the one-MC6000 version right now 'cause this is a Sun Haotian job and I want to get to the good part in the next section. But I can post that prototype later if anyone's interested.
Well, to heck with that.
So, to recap:
Aquaponics Tools: It's modular, so Sun needs to feed a lot of people.
Smart Grid Router: Sun is setting up an electrical grid, or assuming responsibility for one?
...and now we have a stoplight... for a six-way intersection.
It's the "six-way" that's the kicker (and the lack of presence of yellow lights, too). If this were a stoplight for a regular old four-way intersection, I'd put all this together and say that Sun was going to expand or retrofit a city somewhere (the New Mauville treatment?), because that's what this looks like so far. But a six-way intersection that only accepts self-driving cars (maybe)? I don't know of any cities on Earth that naturally use six-way intersections, and the self-driving thing would be waaaaaaaaaay too hard to enforce in an existing city.
Therefore, I propose: Assuming that all of these jobs so far are for the same thing, and are what they say they are, I hazard that Sun Haotian wants to found a city somewhere. The aquaponics suggests to me that it might be somewhere you can't conventionally grow food - maybe up in the north of China where there's a lot of blank space (unused/unusable?) land. (Again, I'm guessing.)
Now the question is— am I right?